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reference. 

This application is related to U.S. Patent Application No. 09/703,356, 
filed October 31 , 2000 (Atty. Dkt. No. SUN1 P810/P5510), entitled 

"IMPROVED METHODS AND APPARATUS FOR NUMERIC CONSTANT 
15 VALUE INLINING IN VIRTUAL MACHINES", filed concurrently herewith, and 
hereby incorporated herein by reference. 



BACKGROUND OF THE INVENTION 

The present invention relates generally to object-based high level 
20 programming environments, and more particularly, to frameworks for loading 
and execution of portable, platform independent programming instructions 
within a virtual machine. 

Recently, the Java™ programming environment has become quite 
popular. The Java™ programming language is an language that is designed 
25 to be portable enough to be executed on a wide range of computers ranging 
from small devices (e.g., pagers, cell phones and smart cards) up to 
supercomputers. Computer programs written in the Java™ programming 
language (and other languages) may be compiled into Java™ virtual machine 
instructions (typically referred to as Java™ bytecodes) that are suitable for 
30 execution by a Java™ virtual machine implementation. 

The Java™ virtual machine is commonly implemented in software by 
means of an interpreter for the Java™ virtual machine instruction set but, in 
general, may be software, hardware, or both. A particular Java™ virtual 
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machine implementation and corresponding support libraries, together 
constitute a Java™ runtime environment. 

Computer programs in the Java™ programming language are arranged 
in one or more classes or interfaces (referred to herein jointly as classes or 
5 class files). Such programs are generally platform, i.e., hardware and 

operating system, independent. As such, these computer programs may be 
executed, unmodified, on any computer that is able to run an implementation 
of the Java™ runtime environment. A class written in the Java™ 
programming language is compiled to a particular binary format called the 

10 "class file format" that includes Java™ virtual machine instructions for the 
methods of a single class. In addition to the Java™ virtual machine 
instructions for the methods of a class, the class file format includes a 
significant amount of ancillary information that is associated with the class. 
The class file format (as well as the general operation of the Java™ virtual 

15 machine) is described in some detail in The Java™ Virtual Machine 

Specification by Tim Lindholm and Frank Yellin (ISBN 0-201-31006-6), which 
is hereby incorporated herein by reference. 

Conventionally, when a class file is loaded into the virtual machine, the 
virtual machine essentially makes a copy of the class file for its internal use. 

20 The virtual machine's internal copy is sometimes referred to as an "internal 
class representation." In conventional virtual machines, the internal class 
representation is typically almost an exact copy of the class file and it 
replicates the entire Constant Pool. This is true regardless of whether 
multiple classes loaded into the virtual machine reference the same method 

25 and thus replicate some (or much) of the same Constant Pool information. 
Such replication may, of course, result in an inefficient use of memory 
resources. In some circumstances (particularly in embedded systems which 
have limited memory resources) this inefficient use of memory resources can 
be a significant disadvantage. 

30 As described in The Java™ Virtual Machine Specification , one of the 

structures of a standard class file is known as the "Constant Pool." The 
Constant Pool is a data structure that has several uses. One of the uses of 
the Constant Pool that is relevant to the present invention is that the Constant 
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Pool contains the information that is needed to resolve various Java™ 
Instructions, for example, a method invocation instruction that can be invoked 
by any of the methods within the class. Fig. 1 A (which may be familiar to 
those skilled in the art) is a representation of a Constant Pool section of a 
5 class file that contains the information necessary to uniquely identify and 
locate a particular invoked method. 

Additionally, conventional virtual machine interpreters decode and 
execute the virtual machine instructions (Java™ bytecodes) one instruction at 
a time during execution, e.g., "at runtime." To execute a Java™ instruction, 

10 typically, several operations have to been performed to obtain the information 
that is necessary to execute the Java™ instruction. For example, to invoke a 
method referenced by a Java™ bytecode, the virtual machine must make 
several operations to access the Constant Pool simply to identify the 
information necessary to locate and access the invoked method. 

15 To illustrate, Fig. 1 B shows an exemplary conventional Java™ 

bytecode stream 150 including virtual machine instructions (typically referred 
to as Java™ bytecodes) that are suitable for execution by a conventional 
Java™ virtual machine. The first bytecode, Java™ bytecode 152 represents 
an arithmetic Java™ "Add" command with no associated parameters. The 

20 second bytecode, Java™ bytecode 154 represents a Java™ "iconst" 

instruction (load an integer constant on the stack). The Java™ bytecodes 156 
and 157, CP-lndexA and CP-lndexB, respectively represent the first and 
second bytes of an index to the constant pool for the integer constant. It 
should be noted that Java™ bytecodes 152, 154 and 156 collectively 

25 represent a Java™ "iconst" instruction. In order to execute the Java™ 

Instruction iconst, at run time, an index to the Constant Pool is constructed 
from the CP-lndexA and CP-lndexA. Once an index to the Constant Pool has 
been determined, the appropriate structures in the Constant Pool have to be 
accessed so that the appropriate constant value can be determined. 

30 Accordingly, the Java™ instruction "iconstant" is executed but only 

after performing several operations at run time. As can be appreciated from 
the example above, the execution of a relatively simple instruction such as 
loading a constant value can take a significant amount of run time. 
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Furthermore, execution of relatively more complex Java™ instructions 
requires even more processing than noted above. For example, in order to 
conventionally execute an invoke method command 158, the constant pool 
has to be accessed several times at run time just to obtain the symbolic 
5 representation of information associated with the method. The CP_lndexC 
and CP_lndexD are indexes to a constant pool where information relating to 
the method including its parameter values needed for execution can be found. 
Accordingly, a CP_lndexD associated with the method instruction 158 is 
typically an index to an entry into the Constant Pool wherein that entry itself 

10 provides another pair of indexes to other entries in the Constant Pool, and so 
forth. Thus, execution of an invoke method command would require a 
significant amount of processing at run time (e.g., accessing the Constant 
Pool several times to obtain symbolic representation relating to the method). 
As will be appreciated, this conventional technique is an inefficient approach 

15 that may result in significantly longer execution times. In addition, once the 
symbolic information relating to the method has been obtained, there may be 
a need to convert the symbolic information into an internal representation at 
run time. Again, this is an inefficient approach. 

Accordingly, there is a need for improved frameworks for loading and 

20 execution of portable, platform independent programming instructions within a 
virtual machine. 
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SUMMARY OF THE INVENTION 



To achieve the foregoing and other objects of the invention, improved 
frameworks for loading and execution of portable, platform independent 
5 programming instructions within a virtual machine will be described. One 
aspect of the present invention seeks to provide a mechanism that will 
generally improve the runtime performance of virtual machines by eliminating 
the need to always traverse a constant pool at runtime to execute a Java™ 
instruction. In effect, the described system contemplates doing some extra 
10 work during the loading of a class into a virtual machine by obtaining the 
information from the constant pool during loading and representing that 
information in a form that can be used more efficiently at runtime. 

In other aspects of the invention, specific data structures that are 
suitable for use within a virtual machine and methods for creating such data 

15 structures are described. In one embodiment, an enhanced Java™ bytecode 
representation having a pair of Java™ bytecode streams is disclosed. The 
enhanced Java™ bytecode has a Java™ code stream suitable for storing 
various Java™ commands as bytecodes within a code stream. A Java™ data 
stream is used to store the data parameters associated with the Java™ 

20 commands in the code stream. As will be appreciated, the invention allows 
for representation of actual parameter values, or references to actual 
parameter values, in the code stream. Accordingly, data parameters can be 
provided for efficient execution of Java™ instructions without requiring further 
processing of Constant Pools at run time. As a result, the performance of 

25 Java™ complaint virtual machine can be enhanced. 

The invention can be implemented in numerous ways, including a 
system, an apparatus, a method or a computer readable medium. Several 
embodiments of the invention are discussed below. 

As a method of creating data structures suitable for use by a virtual 
30 machine to execute computer instructions, one embodiment of the invention 
includes converting a stream, having commands and data associated with the 
commands, into a pair of streams for use in the virtual machine. The pair of 
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streams includes a code stream and a data stream for data associated with 
the commands in the code stream. 

As a data structure for containing computer executable commands and 
data associated with the computer executable commands, the data structure 
5 suitable for use by a virtual machine in an object oriented programming 

environment, one embodiment of the invention includes a code portion having 
one or more computer executable commands, and a data stream having data 
corresponding to the one or more computer executable commands. 

As a method of executing computer instructions on a virtual machine, 

10 one embodiment of the invention includes the acts of: fetching a command 
associated with a computer instruction from a code stream; determining 
whether the command has an associated parameter; fetching from a data 
stream the associated parameter of the command when that command has 
an associated parameter; and executing the command with the associated 

15 parameters after the associated parameter of the commands have been 
fetched. 

-As a method of creating data structures suitable for use by a virtual 
machine to execute Java™ instructions, another embodiment of the invention 
includes converting a Java™ bytecode into a pair of Java™ bytecode streams 

20 suitable for use by the virtual machine. The pair of Java™ bytecode streams 
being a Java™ code stream that includes Java™ commands and a Java™ 
data stream that includes the data associated with the commands in the 
Java™ code stream. 

Other aspects and advantages of the invention will become apparent 

25 from the following detailed description, taken in conjunction with the 

accompanying drawings, illustrating by way of example the principles of the 
invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The present invention will be readily understood by the following 
detailed description in conjunction with the accompanying drawings, wherein 
like reference numerals designate like structural elements, and in which: 

Fig. 1 A is a representation of a Constant Pool section of a Java™ class 

file. 

Fig. 1 B shows an exemplary conventional Java™ bytecode stream 
including virtual machine instructions. 

Fig. 2 is a block diagram representation of Java™ bytecode streams in 
accordance with one embodiment of the invention. 

Fig. 3 illustrates an execution method for executing Java™ bytecode 
instructions in accordance with one embodiment of the invention. 

Fig. 4 illustrates an exemplary bytecode stream generation method in 
accordance with one embodiment of the invention. 

Fig. 5 illustrates an exemplary loading method for loading bytecodes of 
a class file in accordance with one embodiment of the invention. 

Fig. 6 illustrates a processing method for processing a Java™ Load 
constant command in accordance with one embodiment of the invention. 

Fig. 7 illustrates an execution method for executing a Java™ Load 
Constant command in accordance with one embodiment of the invention. 
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DETAILED DESCRIPTION OF THE INVENTION 



As described in the background section, the Java™ programming 
5 environment has enjoyed widespread success. Therefore, there are 

continuing efforts to extend the breadth of Java™ compatible devices and to 
improve the performance of such devices. One of the most significant factors 
influencing the performance of Java™ based programs on a particular 
platform is the performance of the underlying virtual machine. Accordingly, 

10 there have been extensive efforts by a number of entities to provide improved 
performance Java™ compliant virtual machines. In order to be Java™ 
compliant, a virtual machine must be capable of working with Java™ classes, 
which have a defined class file format. Although it is important that any 
Java™ virtual machine be capable of handling Java™ classes, the Java™ 

15 virtual machine specification does not dictate how such classes are 
represented internally within a particular Java™ virtual machine 
implementation. 

The Java™ class file format utilizes the constant pool construct to store 
the information necessary to execute a Java™ instruction at run time. 

20 However, as suggested above, traversing the constant pool at runtime to 
obtain the information necessary to execute Java™ instructions is not 
particularly efficient. One aspect of the present invention seeks to provide a 
mechanism that will generally improve the runtime performance of virtual 
machines by eliminating the need to always traverse a constant pool at 

25 runtime to execute a Java™ instruction. Accordingly, a significant amount of 
work is conventionally performed at runtime. In effect, the described system 
contemplates doing some extra work during the loading of a class into a 
virtual machine by obtaining the information from the constant pool during 
loading and representing that information in a form that can be used more 

30 efficiently at runtime 

In other aspects of the invention, specific data structures that are 
suitable for use within a virtual machine and methods for creating such data 
structures are described. In one embodiment, an enhanced Java™ bytecode 
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representation having a pair of Java™ bytecode streams is disclosed. The 
enhanced Java™ bytecode has a Java™ code stream suitable for storing 
various Java™ commands as bytecodes within a code stream. A Java™ data 
stream of the enhanced Java™ bytecode representation is used to store the 
5 data parameters associated with the Java™ commands in the code stream. 
As will be appreciated, the invention allows for representation in the code 
stream of actual parameter values, or references to actual parameter values. 
Accordingly, data parameters can be provided for efficient execution of Java™ 
instructions without requiring further processing of Constant Pools at run time. 
10 As a result, the performance of Java™ complaint virtual machine can be 
enhanced. 

Furthermore, if the invention is implemented together with other 
improvements as described in concurrently filed, co-pending Application No. 
U.S. Patent Application No. 09/703,361 , filed October 31 , 2000 (Atty. 

15 Dkt._No. SUN1P809/P5500), entitled "IMPROVED FRAMEWORKS FOR 

INVOKING METHODS IN VIRTUAL MACHINES", the constant pool may not 
even need to be copied into the virtual machine's in order to invoke methods. 
Thus, the use of the invention in conjunction with the improved techniques 
provided as described in U.S. Patent Application No. 09/703,361, 

20 filed October 31 , 2000 (Atty. Dkt. No. SUN1 P809/P5500), entitled 

"IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL 
MACHINES" has the potential in many circumstances to even further improve 
the performance of the virtual machines. 

Embodiments of the invention are discussed below with reference to 
25 Figs. 2-7- However, those skilled in the art will readily appreciate that the 
detailed description given herein with respect to these figures is for 
explanatory purposes as the invention extends beyond these limited 
embodiments. 

Fig. 2 is a block diagram representation of Java™ bytecode streams 
30 200 in accordance with one embodiment of the invention. The Java™ 

bytecode streams 200 can be, for example, implemented as a data structure 
embodied in a computer readable medium that is suitable for use by a virtual 
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machine. As shown in Fig. 2, the Java™ bytecode streams 200 includes a 
pair of Java™ bytecode streams, namely, a Java™ code stream 202 and a 
Java™ data stream 204. The code stream 202 includes various Java™ 
commands 206, 208, and 210. The code stream 206 represents a Java™ 
5 command A which does not have any parameters associated with it. On the 
other hand, code streams 208 and 210 represent respectively Java™ 
commands B and C with associated data parameters which are represented 
in the Java™ data stream 204. The Java™ bytecode 212 represents data B 
which is the data parameters corresponding to the Java™ command B of 

10 Java™ code stream 202. It should be noted that the Java™ command B and 
data B together represent a Java™ instruction corresponding to a Java™ 
command B with its associated data. Similarly, the Java™ bytecodes 214 and 
216 represent respectively data C1 and C2 which collectively represent the 
data parameters corresponding to the Java™ command C of Java™ code 

15 stream 202. Accordingly, the Java™ command C, data C1 and data C2 

together represent a Java™ instruction corresponding to a Java™ command 
C with its associate data represented in bytecodes 214 and 216. 

As noted above, the Java™ bytecode 200 streams are suitable for use 
by a virtual machine. Referring now to Fig. 3, an exemplary execution method 

20 300 for executing Java™ bytecode instructions is disclosed. The execution 
method 300 can be used, for example, in conjunction with a pair of Java™ 
bytecode streams, for example, the Java™ code stream 202 and Java™ data 
stream 204. Initially, at operation 302, the next command in the code stream 
is fetched. For example, referring back to Fig. 2, the next command fetched 

25 can be the bytecode 206 of the Java™ code stream 202. Next, at operation 
304, a pointer to the Java™ code stream is incremented to point to the next 
command in the Java™ code stream. Referring again to Fig. 2, a pointer to 
the Java™ code stream 206 is incremented to point to the next command in 
the Java™ code stream, foe example, the bytecode 206 (Java™ command B). 

30 Following incrementing the pointer at operation 304, the execution method 
300 proceeds to operation 306 where a determination is made as to whether 
the fetched command has an associated parameter. If it is determined at 
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operation 306 that the fetched command does not have an associated 
parameter, for example, in the case of Java™ command A of Fig. 2, the 
execution method 300 proceeds directly to operation 312 where the fetched 
command (with no associated parameter) is executed. Thereafter, at 
5 operation 314 a determination is made as to whether there are more 
commands in the Java™ code stream to execute. If it is determined at 
operation 314 that there are no more commands to execute, the execution 
method 300 ends. However, if it is determined at operation 314 that there is 
at least one more command to execute, that execution method 300 proceeds 
10 back to operation 302 where the next command in the code stream is fetched. 

On the other hand, if it is determined at operation 306 that the fetched 
command has an associated parameter, the execution method 300 proceeds 
to operation 308 where the parameter values associated with the fetched 
command are fetched from the data stream. Referring back to Fig 2., for 

15 example, in the case when the fetched command is the Java™ command B of 
bytecode 208, the parameter values associated with Java™ command B, 
namely, data B of the bytecode 212 is fetched. Similarly, in the case of the 
Java™ command C (bytecode 210), data C1 and data C2 (bytecodes 214 and 
216) would be fetched at operation 308. As will be appreciated, the invention 

20 allows for parameter values in the data stream which can represent actual 

parameter values (or references to actual parameter values). Accordingly, the 
data parameters in the data code can be used to execute instructions without 
requiring further processing of Constant Pool. 

After the appropriate data is fetched, at operation 310, the pointer to 
25 the data command stream is incremented to point to the appropriate position 
in the data stream. As will be appreciated, the pointer to the data stream can 
be updated based on the command type (i.e., based on the number of 
bytecodes appropriated for the data associated with the command). When 
the command and the appropriate parameter values have been fetched, the 
30 execution method 300 proceeds to operation 314 where the fetched 

command is executed. Finally, at operation 314 a determination is made as 
to whether there are more commands in the Java™ code stream to execute. 
If it is determined at operation 314 that there are no more commands to 
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execute, the execution method 300 ends. However, if it is determined at 
operation 314 that there is at least one more command to execute, that 
execution method 300 proceeds back to operation 302 where the next 
command in the code stream is fetched. 

5 As noted above, the invention, among other things, provides for a pair 

of Java™ bytecode streams suitable for use by a virtual machine, for example, 
the code stream 202 and a Java™ data stream 204. Referring now to Fig. 4, 
an exemplary bytecode stream generation method 400 for generation of an 
enhanced bytecode representation is disclosed. The bytecode stream 

10 generation can be used, for example, to generate a pair of bytecode streams 
from a conventional Java™ bytecode stream 150 of Fig. 1 . Initially, at 
operation 402, the next bytecode representing a command is read. Next, at 
operation 404, a bytecode representing the command is written into an entry 
of a code stream, for example, the Java™ code stream 202 of Fig. 2. 

15 Following operation 404, a determination is made at operation 406 as to 
whether the command has an associated parameter. If it is determined at 
operation 406 that the command does not have any associated parameters, 
the bytecode stream generation method 400 proceeds directly to operation 
410 where a determination is made as to whether there are more bytecodes 

20 to read. If there are no more bytecodes to process, the bytecode stream 
generation method 400 ends. However, if there is at least one more 
bytecodes to read, the bytecode stream generation method 400 proceeds to 
operation 402 where the next bytecode representing a command is read. 

On the other hand, when it is determined at operation 406 that the 
25 command has associated parameters, the bytecode stream generation 

method 400 proceeds to operation 408 where the associated parameters are 
read and processed. As will be appreciated, the processing of the associated 
parameters can be performed based on the command type in accordance 
with one aspect of the invention. This processing will be further illustrated in 
30 Fig. 5 below. After appropriate processing of associated parameters, at 

operation 409, an appropriate value is written to a data stream, for example, 
the Java™ data stream of Fig. 2. Next, the bytecode stream generation 
method 400 proceeds to operation 410 where a determination is made as to 
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whether there are more bytecodes to read, if there is at least one more 
bytecodes to read, the bytecode stream generation method 400 proceeds to 
operation 402 where the next bytecode representing a command is read. 
However, if there are no more bytecodes to process, the bytecode stream 
5 generation method 400 ends. 

Fig. 5 illustrates an exemplary loading method 500 for loading 
bytecodes of a class file in accordance with one embodiment of the invention. 
For the sake of illustration, in the described embodiment, the loading is used 
in a Java™ runtime environment to load a Java™ class file. The class file can 

10 include various Java™ instructions ( Java™ commands and associated data 
parameters) . Typically, this would be accomplished by a Java™ class loader. 
It should be noted that in the described embodiment the Java™ commands 
are written into a Java™ code stream. Accordingly, the loading method 500 
illustrates loading operations that can be performed to provide the 

15 corresponding Java™ code stream for the Java™ code stream. 

Initially, at operation 502, a determination is made as to whether the 
Java™ command is a load constant command. If it is determined at operation 
502 that the Java™ command is a load constant command, the loading 
method 500 proceeds to operation 504 where the load constant command is 

20 processed in accordance with one aspect of the invention. For example, such 
processing can be performed as illustrated below in Fig. 6. 

On the other hand, If it is determined at operation 502 that the Java™ 
command is not a load constant command, the loading method 500 proceeds 
to operation 506 where a determination is made as to whether the Java™ 

25 command is an invoke method command. If it is determined at operation 506 
that the Java™ command is an invoke method command, the loading method 
500 proceeds to operation 508 where the invoke method command is 
processed in accordance with another aspect of the invention. In a preferred 
embodiment, the invoke method command is processed to create a reference 

30 cell which provides the information necessary to invoke the method at run 
time. For example, such processing can be performed as illustrated in co- 
pending U.S. Patent Application No. 09/703,361 . f iled October 31 . 
2000 (Attv. Dkt. No. SUN1 P809/P5500), entitled "IMPROVED 
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FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES" . 
Accordingly, in the described embodiment, the address of the reference cell 
corresponding to the invoke method command is written into the data stream. 
However, If it is determined at operation 506 that the Java™ command 
5 is not an Invoke method command, the loading method 500 proceeds to 
operation 512 where a determination is made as to whether the Java™ 
command is a Jump command. If it is determined at operation 512 that 
Java™ command is a Jump command, the appropriate code and data stream 
offsets of the Jump command are written into the data stream entry 

10 corresponding to the jump. 

On the other hand, If it is determined at operation 512 that the Java™ 
command is not a jump command, the loading method 500 proceeds to 
operation 516 where a determination is made as to whether the Java™ 
command is an instantiation command. As will be appreciated, if it is 

15 determined at operation 516 that the Java™ command is an instantiation 
command, the Constant pool information for the instantiation command can 
be processed at operation 518. Following operation 518, in the described 
embodiment, the appropriate type-descriptor is written into the data stream at 
operation 520. However, if it is determined at operation 516 that the Java™ 

20 command is not an instantiation command, the loading method 500 proceeds 
to operation 522 where it is determined whether the Java™ command is a 
Get/Put field command. 

As will be appreciated, if it is determined at operation 522 that the 
Java™ command is a Get/Put field command, the Constant pool information 

25 for the instantiation command can be processed at operation 518. For 
example, a reference cell which provides the information necessary to 
execute the Get/Put field command at run time can be generated. 
Accordingly, following operation 524, the address of a reference cell 
corresponding to the Get/Put field command can be written into the data 

30 stream at operation 526. The loading method 500 ends if it is determined at 
operation 522 that the Java™ command is not a Get/Put field command. 

Fig. 6 illustrates a processing method 600 for processing a Java™ 
Load constant command in accordance with one embodiment of the invention. 
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The processing method 600 represents operations that can be performed, for 
example, at operation 508 of Fig. 5. It should be noted that the processing 
method 600 can be used to convert a conventional representation of a Load 
constant command with its associated parameter (e.g., bytecodes 154, 156, 
5 and 157 of Fig 1). Accordingly, the processing method 600 can be used to 
represent the Load constant command and its associated parameter 
respectively into a Java™ code stream and a Java™ data stream, for 
example, the Java™ code stream 202 and Java™ data stream 204 of Fig. 2. 
Initially, at operation 602, the first bytecode of the Constant Pool index 

10 (e.g., bytecode 156 of Fig. 1) is fetched. Next, at operation 604, the second 
bytecode of the Constant Pool index (e.g., byte code 157 of Fig. 1 ) is fetched. 
As will be appreciated, at operation 606, the Constant Pool index is 
constructed from the first and second fetched bytes. After construction of the 
Constant Pool index, appropriate data structures of the Constant Pool are 

15 read at operation 608. Next, at operation 610, the corresponding constant 
value is determined based on the constant information read at operation 608. 
As will appreciated, other operations can be performed, for example, if 
necessary, byte alignment can be performed at operation 610. Finally, at 
operation 612 the constant value determined at operation 610 is written into a 

20 Java™ data stream, for example, the Java™ data stream 204 of Fig. 2. It 

should be noted that corresponding Java™ Load constant command is written 
into an appropriate entry of a Java™ code stream, for example, the Java™ 
code stream 202 of Fig. 2. 

Fig. 7 illustrates an execution method 700 for executing a Java™ Load 

25 Constant command in accordance with one embodiment of the invention. It 
should be noted that the execution method 700 can be implemented in a 
virtual machine in conjunction with an enhanced bytecode representation to 
allow more efficient run time execution of a Java™ Load Constant command. 
For example, the processing method 600 can be used to generate the 

30 bytecode streams 200 having the Java™ code stream 202 and Java™ data 
stream 204. Accordingly, The Java™ Load Constant command can be stored 
in the code stream while the corresponding Constant parameters value are 
stored in the data stream. 
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Initially, at operation 702, the Java™ Load Constant command is 
fetched from the code stream. For example, referring back to Fig. 2, the 
bytecode 206 of the Java™ code stream 206 (Java™ command A), 
representing a Java™ Load Constant command is fetched from the Java™ 
5 code stream 202. Next, at operation 704, a pointer to the Java™ code stream 
is incremented to point to the next command in the Java™ code stream. 
Referring again to Fig. 2, a pointer to the Java™ code stream 206 is 
incremented to point to the next command in the Java™ code stream, namely, 
code stream 206 (Java™ command B). Following incrementing the pointer at 

10 operation 704, the execution method 700 proceeds to operation 706 where it 
is determined how many bytecodes corresponding to the Constant parameter 
value needs to be fetched from the Java™ data stream. As will appreciated 
this determination can be made based on the Constant's type (e.g., double, 
integer, float, etc.). Accordingly, at operation 708, the appropriate number of 

15 bytes which correspond to -the Constant parameter value are fetched. 

After the appropriate constant value is fetched, at operation 710, the pointer to 
the data command stream is incremented to point to the appropriate position 
in the data stream. As will be appreciated, the pointer to the data stream can 
be updated based on the type of the Load constant command (i.e., based on 

20 the number of bytecodes appropriated for the data associated with the 
command). Finally, at operation 712, the Constant Load command is 
executed, for example, the appropriate Constant value command in pushed 
on the stack. 

The many features and advantages of the present invention are 
25 apparent from the written description, and thus, it is intended by the appended 
claims to cover all such features and advantages of the invention. Further, 
since numerous modifications and changes will readily occur to those skilled 
in the art, it is not desired to limit the invention to the exact construction and 
operation as illustrated and described. Hence, all suitable modifications and 
30 equivalents may be resorted to as falling within the scope of the invention. 

What is claim d is: 
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CLAIMS 



1 . A method of creating data structures suitable for use by a virtual machine to 
execute computer instructions, the method comprising: converting a stream of 
commands and data associated with the commands into a pair of streams for 
use in the virtual machine, the pair of streams including a code stream that 
includes the commands and a data stream that includes the data associated 
with the commands in the code stream. 

2. A method as recited in claim 1 , wherein the code stream includes only 
commands and the data stream includes only the data associated with the 
commands in the code stream. 

3. A method as recited in claim 1 , wherein the stream that is to be converted 
is a Java bytecode stream, the code stream is a Java bytecode code stream 
that includes Java commands, and the data stream is a Java bytecode data 
stream that includes the data associated with the Java commands in the java 
bytecode code stream. 

4. A method as recited in claim 1 , wherein said converting of said stream 
comprises: 

writing a representation of a first command associated with a first 
instruction into a code entry of the code stream; 

determining whether the first command has data associated with it; and 
writing a representation of the associated data or a reference to a 
representation of the data associated with the first command into a first data 
entry of the data stream when the command has an associated data. 

5. A method as recited in claim 4, wherein the stream that is to be converted 
is a Java bytecode stream, the code stream is a Java bytecode code stream 
that includes Java commands, and the data stream is a Java bytecode data 
stream that includes the data associated with the Java commands in the java 
bytecode code stream. 
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6. A method as recited in claim 4, wherein said method further comprises: 

not providing a data entry in the data stream for the command when 
the command does not have data associated with it. 

7. A method as recited in claim 6, wherein said method further comprises: 

writing a representation of second command associated with another 
instruction into a second code entry of the code stream; 

determining whether the second command has data associated with it; 

and 

writing a representation of the associated data or a reference to a 
representation of the data associated with the second command into a second 
data entry of the data stream when the command has associated data. 

8. A method as recited in claim 7, wherein the stream that is to be converted 
is a Java bytecode stream, the code stream is a Java bytecode code stream 
that includes Java commands, and the data stream is a Java bytecode data 
stream that includes the data associated with the Java commands in the java 
bytecode code stream. 

9. A method as recited in claim 8, 

wherein the command and data entries can each include a number of 
bytecodes in the Java bytecode stream, 

wherein the number of bytecodes is an integer, and 
wherein each byte code can be one or more bytes. 

10. A method as recited in claim 9, wherein the first and second entries of the 
code stream are adjacent to each other. 

11. In an object oriented programming environment, a data structure for 
containing computer executable commands and data associated with the 
computer executable commands, the data structure suitable for use by a 
virtual machine and comprising: 
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a code portion having one or more computer executable commands ; 

and 

a data stream having data corresponding to the one or more computer 
executable commands. 

12. A data structure as recited in claim 1 1 , wherein the code portion does not 
include any data associated with the computer executable commands and the 
data portion does not include any computer executable commands. 

13. A data structure as recited in claim 1 1 , wherein the code portion is a code 
stream that includes Java commands represented as bytecodes, and the data 
portion is a code stream that includes the data associated with the Java 
commands represented as bytecodes. 

14. A data structure as recited in claim 13, 

wherein the code stream and the data stream each comprise of a 
plurality of Java byte codes representing a Java bytecode stream, 

wherein each Java command and data associated with that command 
are represented respectively in one or more bytecodes of the code stream 
and the data stream, and 

wherein each bytecode can be one or more bytes. 

15. A data structure as recited in claim 14, wherein the Java commands can 
be a load constant command, an invoke method command, a jump command, 
an instantiation command, or a get/put field command. 

16. A method of executing computer instructions on a virtual machine, the 
method comprising: 

fetching a command associated with a computer instruction from a 
code stream; 

determining whether the command has an associated parameter; 

fetching from a data stream the associated parameter of the command 
when said determining determines that command has an associated 
parameter; and 
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executing the command with the associated parameters after the 
associated parameter of the commands have been fetched. 

17. A method as recited in claim 16, wherein the method further comprises: 

updating a pointer to the command stream; and 
updating a pointer to the data stream. 

18. A method as recited in claim 16, wherein the code stream includes Java 
commands represented as bytecodes, and the code stream includes data 
associated with the Java commands represented as bytecodes. 

19. A method as recited in claim 18, 

wherein the code stream and the data stream each comprise of a 
plurality of Java byte codes representing a Java bytecode stream, 

wherein each Java command and data associated with each Java 
command are represented respectively, in one or more bytecodes of the code 
stream and the data stream, and 

wherein each bytecode can be one or more bytes. 

20. A method as recited in claim 19, wherein the Java commands can be a 
load constant command, an invoke method command, a jump command, an 
instantiation command, or a get/put field command. 

21 . A method of creating data structures suitable for use by a virtual machine 
to execute Java instructions, the method comprising: 

converting a Java bytecode into a pair of Java bytecode streams 
suitable for use by the virtual machine, the pair of Java bytecode streams 
having a Java code stream that includes Java commands and a Java data 
stream that includes the data associated with the commands included in the 
code stream 

22. A method as recited in claim 21, wherein said converting of said stream 
comprises: 
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writing a representation of a first command associated with a first 
instruction into a code entry of the code stream; 

determining whether the first command has associated data; and 

reading the associated data from a Constant Pool when the command 
has an associated data; 

processing the associated data from the Constant Pool the associated 
data from the Constant Pool; 

writing a representation of the associated data or a reference to a 
representation of the data associated after said processing of the associated 
data; 

wherein each Java command and data associated with that Java 
command are represented respectively in one or more bytecodes of the Java 
code stream and the Java data stream, and 

wherein each bytecode can be one or more bytes. 

23. A method as recited in claim 22, wherein said processing operates to 
determine a constant value associated with a Java Load Constant command. 

24. A method as recited in claim 22, wherein said processing operates to 
determine a reference to a method invocation cell that includes information 
relating to a Java invoke method command. 

25. A method as recited in claim 22, wherein said processing operates to 
determine the code stream offset and data stream offset associated with a 
Java Jump command. 

26. A method as recited in claim 22, wherein said processing operates to 
process a Constant Pool associated with a Java instantiation command. 

27. A method as recited in claim 22, wherein said processing operates to 
process a Constant Pool associated with a Java Get/Put field command. 

28. A method as recited in claim 22, wherein said processing operates to 
process data associated with a Java load constant command, a Java invoke 
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method command, a Java jump command, a Java instantiation command, or 
a Java get/put field command. 
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IMPROVED FRAMEWORKS FOR LOADING AND EXECUTION 
OF OBJECT-BASED PROGRAMS 



ABSTRACT OF THE DISCLOSURE 

Improved frameworks for loading and execution of portable, platform 
independent programming instructions within a virtual machine are described. 
The improved frameworks provides a mechanism that will generally improve 
the runtime performance of virtual machines by eliminating the need to always 
5 traverse a constant pool at runtime to execute a Java™ instruction. In 
addition, specific data structures that are suitable for use within a virtual 
machine and methods for creating such data structures are described. 
Accordingly, an enhanced Java™ bytecode representation having a pair of 
Java™ bytecode streams is disclosed. The enhanced Java™ bytecode has a 

10 Java™ code stream suitable for storing various Java™ commands as 
bytecodes within a code stream. A Java™ data stream of the enhanced 
Java™ bytecode representation is used to store the data parameters 
associated with the Java™ commands in the code stream. Actual parameter 
values, or references to actual parameter values can be provided in the data 

15 stream. Thus, data parameters can be provided for efficient execution of 
Java™ instructions without requiring further processing of Constant Pool at 
run time. As a result, the performance of Java™ complaint virtual machine 
can be enhanced. 



Atty. Dkt. No. SUN1P814/P5417 23 



